Determine how the enterprise architecture can be best implemented to take advantage of the organization's business culture. This should include the creation of an Implementation Factor Assessment and Deduction matrix (see Create an Implementation Factor Assessment and Deduction Matrix) to serve as a repository for architecture implementation and migration decisions. It should also include an assessment of the organizations involved, their culture, and abilities.

For organizations where end-to-end enterprise architecture is well established, this step can be simple, but the matrix has to be established so that it can act as a repository of decisions.

Create an Implementation Factor Assessment and Deduction Matrix

The creation of an Implementation Factor Assessment and Deduction matrix ensures that relevant factors are considered and documented. It should become part of the Implementation and Migration Plan and document the rationale for key architecture decisions in this phase. These factors will help to identify solutions and opportunities and simplify the formulation of the Implementation and Migration Plan.

For a description of the Implementation Factor Assessment and Deduction matrix, see Part III, Implementation Factor Assessment and Deduction Matrix .

Assess Transition Capabilities of Corporate and Partner Organizations

Assess the capability to transition for the corporate organization and any partner organizations that are part of the corporate workflows (e.g., supply chain). The assessment should address at least the following factors:

• The organizational impact on shaping the Transition Architecture, such as how the business units or lines of business co-ordinate their activities; for example, the solution will be different for a company that is decentralized consisting of regional business units controlling all lines of business in their area versus a company that is organized along lines of business globally with strong central control
• The assignment of responsibilities within the organization for the implementation, so that the enterprise architecture becomes entrenched within the organization
• Corporate cultural influences for handling change; for example, a small to medium size organization in a rapidly evolving industrial sector with intense competitive pressures may change at a different rate than a large global company or government where there are more dependencies and the scale of the business transformation is more significant

These factors should be documented in the Implementation Factor Assessment and Deduction matrix.

Assess Transition Capabilities of the Enterprise and IT Organization

Conduct an assessment of the enterprise, and specifically the IT organization, to ensure that at least the following factors are addressed:

• The organization and culture of the enterprise and the IT organization; for example, a de-centralized enterprise and/or IT culture organized regionally or along lines of business will be different to deal with than a centralized enterprise and/or IT organization delivering corporate shared services
• The enterprise personnel skill sets; these could be a major limitation to realizing a Target Architecture that needs a major shift in skill sets - this assessment can determine whether training and/or contracted assistance and/or outsourcing may be required in certain areas
• The gap analysis between the Baseline and Target Architectures; it can be useful to compare the Technical Reference Models produced for the Baseline and Target Architecture as a way to systematically assess services

These factors should be documented in the Implementation Factor Assessment and Deduction matrix.

Identify any business drivers that would constrain the sequence of implementation. This should include a review of the corporate and line of business strategic and business plans and a review of the Enterprise Architecture Maturity Assessment.

Review Corporate Strategic Plan

Perform a review of the corporate strategic and business plans in order to validate the fundamental business drivers for the enterprise architecture so that the enterprise architecture can explicitly address each one. As these drivers may not be self-evident or even documented (e.g., the company is in merger discussions or in the process of either acquiring or being acquired) it is important to discover them as they could have a major impact on Transition Architectures and the associated Implementation and Migration Plan.

Each of the business drivers should be assessed with respect to implementation issues and documented in the Implementation Factor Assessment and Deduction matrix.

Review the Enterprise Architecture Maturity Assessment

Review the enterprise architecture maturity assessment that was conducted in the Preliminary phase and update the Implementation Factor Assessment and Deduction matrix with any actions, activities, initiatives, and projects that have to be undertaken.

Review Corporate Line-of-Business Strategic Plans

Perform a review of the line of business strategic and business plans in order to identify any initiatives, portfolios, projects, or activities that could be leveraged to accelerate the move to the Target Architecture.

This assessment will also determine whether there are any initiatives that could create problems for the enterprise architecture implementation. For the latter, the deductions should be in the form of mitigating efforts including changes to the enterprise architecture or to the line-of-business plan, or both.

Document all of the factors and deduced actions in the Implementation Factor Assessment and Deduction matrix.

Consolidate and integrate the gap analysis results from the Business, Information Systems, and Technology Architectures (created in Phases B to D) and assess their implications with respect to potential solutions/opportunities and inter-dependencies.

Create a Consolidated Gaps, Solutions, and Dependencies Matrix

Create a Consolidated Gaps, Solutions, and Dependencies matrix, as described in Part III, Consolidated Gaps, Solutions, and Dependencies Matrix . This enables identification of SBBs which could potentially address one or more gaps and their associated ABBs.

In the course of the activity, any additional "factors" should be added to the Implementation Factor Assessment and Deduction matrix.

Review the Phase B, C, and D Gap Analysis Results

The gap analysis results from each one of the architecture phases should be reviewed and consolidated in one long list that will become the basis for the work breakdown structure.

The gaps should be consolidated along with potential solutions to the gaps and dependencies. A recommended technique for determining the dependencies is to create a CRUD (Create, Read, Update, and Delete) to relate business functions to information.

In the course of the activity, any additional "factors" should be added to the Implementation Factor Assessment and Deduction matrix.

Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix

Once all of the gaps have been documented, re-organize the gap list and place like items together. When grouping the gaps, refer to the factor assessment table and review the implementation factors. This will lead into the next step when examining functional requirements.

In the course of the activity, any additional "factors" should be added to the Implementation Factor Assessment and Deduction matrix.

Assess the IT requirements, gaps, solutions, and factors to identify a minimal set of functional requirements whose integration into work packages would lead to a more efficient and effective implementation of the Target Architecture.

This functional perspective leads to the satisfaction of multiple requirements through the provision of shared solutions and services. The implications of this consolidation of requirements with respect to architectural components can be significant with respect to the provision of resources. For example, several requirements raised by several lines of business are resolved through the provision of a shared set of IT services within a work package/project. In many organizations the funding of these services by multiple lines of business is an issue that has to be addressed at the CxO level.

Assess the IT Requirements from a Functional Perspective

Review all of the information acquired so far to determine whether the solutions to the "gaps" can be functionally consolidated. The requirements so far collected should also be assessed in conjunction with the Target Architecture, the Consolidated Gaps, Solutions, and Dependencies matrix, and the Implementation Factor Assessment and Deduction matrix for verification and review.

This activity consolidates the requirements functionally and groups them together to act as the basis for work packages. A major benefit will be the reduction to an absolute minimum of projects that have to be managed, administered, and co-ordinated.

Once this is completed, then refine the Consolidated Gaps, Solutions, and Dependencies matrix, listing the new "gaps" that will form the basis for work packages.

Determine Issues Associated with Functional Integration

Often, requirements can be derived and funded in a siloed manner aligned with corporate business processes, leading to the same functionality being required (and possibly delivered) in many different places.

The Target Architecture offers an integrated solution with little or no redundancy, but the integration of requirements, and the associated funding often by lines of business, may be problematic. A useful heuristic is that it costs about twice as much to build a generic re-usable component or service versus a single-purpose component. An individual line of business may not wish to absorb the cost of building a shared service. An assessment of this issue may lead to a modification of the enterprise architecture to be less efficient, but still ensure that line of business funding is maintained.

These issues and outcomes should be documented in the Implementation Factor Assessment and Deduction matrix and, as required, included in the Consolidated Gaps, Solutions, and Dependencies matrix.

Consolidate interoperability requirements identified in previous phases. Reconcile the consolidated requirements with potential solutions.

Consolidate Interoperability Requirements

During Phase A (Architecture Vision), the corporate operating model and interoperability levels should have been clearly defined and the latter refined in Phases B though D following the guidance described in Part III, Interoperability Requirements .

The Architecture Vision and Target Architectures, as well as the Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix, should now be consolidated and reviewed to look for any constraints on interoperability required by the potential set of solutions.

Reconcile Interoperability Requirements with Potential Solutions

The enterprise architect will have to ensure that there are no interoperability conflicts, especially if there is an intention to re-use existing SBBs and/or Commercial Off-The-Shelf (COTS) products, or third-party service providers.

The most significant issue to be addressed is business interoperability. Most SBBs, COTS, or third-party service providers will have their own business processes. Changes to embedded business processes will often require so much work that the advantages of re-using solutions will be lost. An alternative approach is to review business processes embedded within the Target Architecture and see whether they can be aligned with the SBB, COTS, or third-party service provider processes, and supporting Information Systems and Technology Architecture. The enterprise architect will have to ensure that any change to the Target Architecture or the SBB, COTS, or third-party service provider is signed off by the business architects and architecture sponsors in a revised Statement of Architecture Work.

Refine the initial dependencies, ensuring that any constraints on the Implementation and Migration Plans are identified.

There are several key dependencies, described below, that have to be taken discretely into account, namely:

• Business dependencies
• Information dependencies
• Workflow dependencies
• IT dependencies
• Foundation dependencies

In assessing the dependencies, examine the projects and see whether logical increments of deliverables can be identified. The dependencies will also help to identify when the identified increment can be delivered. Once finished, these dependencies should be grouped into a Dependency Analysis Report that becomes a governance artifact as part of the Transition Architecture, and serves as the basis for migration planning.

Assess Business Dependencies

Business dependencies are matters outside of the IT domain that impact the successful delivery of the IT service. These dependencies, when taken into a business capability-based planning perspective (see Part III, Capability-Based Planning), could include matters such as:

• Professional development and training to implement, operate, and sustain the IT capability in both a business and technical context
• Infrastructure that is to provide the physical building to house the new business capability enhanced by IT (e.g., corporate data fusion center)
• Processes that enable the business use of the IT capability through the establishment of workflows, processes, and governance arrangements to ensure that the IT resources can be appropriately leveraged
• Policies, including government legislation, that guide the development of and use of the IT resources

Assess Information Dependencies

Information dependencies have to be assessed to ensure that IT resources and systems that create the data precede those that use the data. This can be achieved through the development of an information sequence for the projects, as described in the Phase C (Data Architecture).

It is recommended that the CRUD (Create, Read, Update, and Delete) matrix created in Review and Consolidate Gap Analysis Results from Phases B to D be used to help sequence the projects such that projects that create information precede projects that read or update that information. Laying out the projects in that manner will be a valuable guide for the transformation planners.

Assess Workflow Dependencies

Business workflow dependencies include those that ensure that work processes are supported in a logical manner so that the workflows can be implemented in an incremental manner and as expeditiously as possible. This is closely linked to the information dependencies, but is more subtle as it relies on the support of workflow steps in a logical business-driven manner.

This could be sequential (e.g., Steps 1, 2, 3, and so on) or business-driven (e.g., Step 1, 5, 4, 6, and so on) depending upon the requirements. Sequential is straightforward to deal with, but the business-driven steps require a solid understanding of what the real business needs are.

Capability-based planning (refer to Part III, Capability-Based Planning), for example, would see business sponsors and architects co-ordinating a series of projects and project increments to deliver business value on a continual basis. The fully implemented ideal workflow could well be preceded by an abbreviated one focusing on the critical and/or high return on investment processes.

Assess IT Dependencies

IT dependencies include those endeavors outside of the IT portfolio whereby IT resources/systems are critical to the achievement of their business capabilities. These could be triggered by business policy decisions. For example, the Business Re-engineering Group has deemed that a decrease in the corporate workforce could be compensated for through the introduction of new business processes enabled by IT. In this case, the delivery of certain key IT resources may be predicated by the wave of retirements in certain areas.

Some of the areas containing these dependencies are referred to in Part III, Capability-Based Planning , specifically the capability dimensions.

Assess Foundation Dependencies and Interim Capabilities

Foundation dependencies include the assessment of the required resources, determining the optimal implementation path within the constraints of the enterprise's capacity for creating and absorbing change.

This "molding" to enable the continuous provision of business capabilities may necessitate the creation of interim or partial SBBs. For example, the creation of a partial information environment with information provider applications may be necessary for the first applications creating the information.

Avoid an "all or nothing" approach. For example, the management of client information does not require the presence of an entire information environment or a complete corporate data model. A minimal subset that will enable the initial applications to show business values will suffice and ensure that the funding envelope will be sustained for the fuller implementation of the Target Architecture.

Often, enterprise architecture involves top-down design and bottom-up implementation; however, the need to deliver business value in the short term will most likely necessitate implementation compromises and creates planned rework. The foundation dependencies will highlight the impact of decisions made and the extent of the rework that should be factored into the final resource bill.

Rationalize and Consolidate Dependencies

Dependency rationalization and consolidation includes the integration of the dependencies, many of which will have been repeated in the different areas. These dependencies should be included in a Dependency Analysis Report that will be part of the documentation of the Implementation and Migration Plan and will become a governance artifact.

Assess the readiness of the organization to undergo the business transformation changes necessary to leverage the enterprise architecture. Assess the ability of the organization to adapt to change and capture the associated risks. The actual Business Transformation Readiness Assessment or equivalent will have been conducted in Phase A as part of the Architecture Vision and the accompanying roadmap.

At this point, the architects should review the findings and determine the impact of the findings on the Transition Architecture.

There will always be risks associated with any transformation effort and it is important to identify, classify, and mitigate them before starting so that they can be tracked throughout any specific transformation effort. See Part III, Business Transformation Readiness Assessment for a detailed description of the conduct of a Business Transformation Readiness Assessment, and Risk Management for a Risk Management Framework.

In enterprise architecture, the shortest distance between two points (the Baseline and Target Architectures) may not be a straight line, but rather a more indirect path that the organization can realistically negotiate. The determination of this path will be key in identifying what the Transition Architectures will be.

The outcome will help the enterprise architect to determine implementation approaches that will be culturally as well as technically feasible for both tactical and strategic success.

Create an overall solutions strategy that will guide the Target Architecture implementation and structure the Transition Architectures.

The first activity is to determine an overall strategic approach to implementing the solutions and/or exploiting opportunities. The move to a new architecture paradigm (e.g., SOA) will require a different strategy to the upgrade of existing IT infrastructure. Formulation of an appropriate strategic approach will rely on the analysis of the previously identified risks.

Next, determine an approach to implement the overall strategic direction just selected, that will address and mitigate the risks identified in the Consolidated Gaps, Solutions, and Dependencies matrix.

In all cases, there is a need for high-level business and technical consensus as the implications of the approach could be significant. For example, a strategic investment could be highly profitable in the long term, but have a significant negative impact on stock price in the short term unless properly communicated.

Determine Overall Strategic Implementation Direction

Once the enterprise's capacity to create and absorb change is understood, it is important to determine what strategic approach will be taken to implement the Target Architecture. This critical step is often overlooked and the Target Architecture is decomposed into a series of projects that proceed independently with unfortunate results. Stakeholders need to know how the strategic goals are to be achieved.

Essentially there are three basic approaches as follows:

• Greenfield: start from the beginning
• Revolutionary: radical change (switch on, switch off); need for major surge resourcing (double/shadow system)
• Evolutionary: includes strategy of convergence; a phased approach is needed to introduce most capabilities

The greenfield and revolutionary approaches may be the most profitable strategically, but the intermediate costs must be taken into account, with the potential necessity to sustain two parallel environments. The costs are more than fiscal, but also include the impact of business transformation and a de facto reduction in management flexibility during the transition period. If either of these two approaches is adopted, then the impact on the Transition Architectures could be significant and, potentially, the Transition Architecture period could be significantly extended with in-service use being scheduled at a future point in time.

By far, the most common approach is the evolutionary one with ever-increasing levels of capability being introduced into the enterprise supported by a strategy of convergence to gradually integrate the existing corporate IT infrastructure.

It is recommended to collaborate with enterprise stakeholders to select a transformation approach and then to ensure that the resources will be provided to support its implementation.

Determine an Implementation Approach

The implementation approach addresses how the strategic implementation direction is to be executed to provide direction to both architects and portfolio/project managers alike.

The most common implementation methodology recommendations include:

• Quick win (snapshots)
• Achievable targets
• Value chain method (e.g., NASCIO methodology)

These approaches and the identified dependencies should become the rationale basis for the creation of the Transition Architectures.

This activity terminates with agreement on the Implementation and Migration Strategy for the enterprise.

Logically group the architectural activities into a coherent set of portfolios and projects, respecting the strategic implementation direction and approach.

Using the Consolidated Gaps, Solutions, and Dependencies matrix and Implementation Factor Assessment and Deduction matrix, logically group the various activities into work packages (where a work package is an inter-dependent set of activities and deliverables that deliver a discrete enterprise outcome). Although the outcome will be at the enterprise level, the work packages may not necessarily have a direct business outcome but might deliver a foundation artifact that will support other work packages that do. The architecture is a way to communicate the value of all work.

Then, analyze and refine these activities with respect to their business transformation issues and the agreed to strategic implementation approach.

Finally, group the work packages into portfolios and then projects within the portfolios taking into consideration the dependencies and the strategic implementation approach.

Identify Major Work Packages

Examine the Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix. Add a column to the latter that recommends the proposed solution mechanism.

The best way to conduct this is to hold a working session with the domain architects and operations management personnel to determine what potentially the best solutions would be.

Indicate for every gap/activity whether the solution should be oriented towards:

• New development
• Based upon a existing product and/or solution that can be purchased

An existing system may resolve the requirement with minor enhancements.

For new development, this is a good point to determine whether the work is to be conducted in-house or through a contract, possibly requiring the involvement of procurement experts. Especially in government, significant lead times should be allowed, to perform the Request for Proposals/Quotes (RFP/RFQ) processes involved in awarding a contract.

Finally, group like solutions together as potential work packages.

By the end of this activity, there should be a re-grouped Consolidated Gaps, Solutions, and Dependencies matrix with an additional column addressing proposed solutions.

It might be useful to classify every current system as:

• Mainstream Systems: part of the future information system.
• Contain Systems: Expected to be replaced or modified in the planning horizon (next three years).
• Replace Systems: To be replaced in the planning horizon.

Analyze the Work Packages with Respect to Business Transformation

The enterprise architect should assess the business transformation-related activities and group them together as potential projects.

For example, as a result of the business transformation, a new line of business may be formed, so it may well be logical for activities pertaining to this new organization to be grouped together so that they can take ownership of the activities and mold them to their needs. In many organizations details are sometimes protected and the enterprise architecture team has to be sufficiently trusted to be perceived as key players and facilitators in the business transformation process.

The work packages should be re-grouped with respect to dependencies (including workflow) and this final analysis used as the basis for project identification. Slightly harder to identify are the projects required to update or replace existing functions which must be done differently in the new environment. One of the options to be considered here is leaving an existing system in place, retro-fitted to be able to co-exist with the new environment.

Once the projects are identified, then their project charter and scope statements should be clearly written and initial (i.e., order of magnitude) resource estimates completed. The benefits can also now be framed in the context in an enterprise-wide context using the enterprise architecture. High return on investment projects should be identified as potential pathfinders to show early success.

During this final step in the specification of building blocks it must be verified that the organization-specific requirements will be met. Key to this is checking against the original business scenario(s) driving the scope of the projects. It is important to note that the ensuing development process must include recognition of dependencies and boundaries for functions and should take account of what products are available in the marketplace. An example of how this might be expressed can be seen in the building blocks example (see Part IV, Building Blocks).

Where the scope of change required to realize the Target Architecture requires an incremental approach, then the enterprise architects will need to develop a series of Transition Architectures as necessary.

Development of Transition Architectures must be based upon the preferred implementation approach, the Consolidated Gaps, Solutions, and Dependencies matrix, the listing of projects and portfolios, as well as the enterprise's capacity for creating and absorbing change. At this point, business capabilities and the supporting projects and portfolios will be broken down into realizable increments.

Transition Architectures provide an ability to continuously deliver business value. This must be measurable and either direct or indirect (i.e., supporting, foundational) business value. Transition Architectures do not have to be of uniform duration, but the timing of the Transition Architectures should not be considered at this point as it will be dealt with in the Migration Plan.

Finally, group the projects and portfolios into Transition Architectures.

Identify Transition Architecture and Capability Increments

Key stakeholders, planners, and the enterprise architect(s) will re-assess the missing business capabilities identified in the Architecture Vision and Target Architecture. They will decompose these targeted capabilities into capability increments each having clearly identified and measurable business value. The supporting top-level projects are in their turn decomposed into increments to deliver the capability increments.

It is useful to determine where the "hard" activities are. Unless there are compelling reasons, do not attack the hardest activities first. Rather, focus on activities that most easily deliver missing capability. Through the development of missing capability and any associated improvement to create and absorb change, perform hard activities, and manage associated risks, the enterprise's capacity will increase.

Most of the challenges in creating and absorbing change are challenges based upon an enterprise's maturity and are expressed in organization and cultural barriers to change.

If there is a business transformation organization within the enterprise, its staff should be involved in definition of capability increments, as they will often have to synchronize several enterprise portfolios delivering their part of the overall transformed set of capabilities. At this point, it may be desirable to assign capability managers whose job it will be to align all of the projects delivering their part of the capability increment.

This co-operation between the architects and business transformation office will help ensure co-ordination and at the same time facilitate the future approval (and release of resources) for the Implementation and Migration Plan.

The collaborative creation of capability increments should identify what activities and outcomes can be grouped together and roughly in what sequence they should be delivered.

Group Portfolios and Projects into Increments

This activity takes the sequence of activities and outcomes and groups the delivery vehicles (the portfolios and projects) into increments, specifying what should be delivered in each increment.

The projects should be broken down into increments based upon the deliverables required in each one of the Transition Architectures.

The approach is to complete the portfolio and major project charters with their deliverables being grouped into increments and scheduled for release within Transition Architecture increments. These architectures provide the enterprise context allowing projects to start their system development methodology initiation, planning, and requirements assessment phases.

Subsequently, the Architecture Vision, Architecture Definition Document, and Architecture Requirements Specification are updated with any additional relevant outcomes from this phase.

Create the Portfolio Charters

Review and consolidate the portfolio and potentially major project charters and ensure that their architectural outcomes are clearly defined.

These architectural outcomes will give the portfolios enterprise context and determine the "fit" and "value" of the deliverables for governance.

Create the Project Charters

Review and consolidate the project charters and ensure that their architectural outcomes are clearly defined.

These architectural outcomes will give the projects enterprise context and determine the "fit" and "value" of the deliverables for governance.

These project charters will enable the projects to start with their system development method in particular initiation, planning, and requirements gathering.

Create the Transition Architectures

Create Transition Architectures that will form the basis for Migration Planning in Phase F. These Transition Architectures should have a clear set of outcomes and a specification of which delivery vehicle (portfolios/projects) will deliver them.

Generally speaking, each Transition Architecture will be expressed at a similar level of detail to the Architecture Definition Document developed in Phases B, C, and D. Where significant additional detail is required, the architect may elect to re-visit Phases B, C, and D for further elaboration. Alternatively, the architecture definition work could be deferred to a future work effort.

Conduct Overall Architecture Updates

Update the Architecture Vision with interoperability policy decisions and any other information that will remain relatively stable for the strategic duration and is largely technology-independent. The Architecture Vision also identifies all of the business capabilities that are to be implemented, and the subset of these capabilities that are to be implemented in the initial Architecture Definition Document.

The narrower scope of the Architecture Definition Document has to have a definitive list of targeted capabilities grouped into Transition Architectures that deliver capability increments through specific projects. The scope of each project is included within their charters that are outlined in the Architecture Definition Document.